The integration of the participatory simulation in a collaborative framework requires at least the possibility of a multiple interface.
%
%The necessity of a multiple interface to integrate the participatory simulation in a collaborative framework
%for modelling and simulation on the complex system
%requires a conception of a generic construction for such a group-ware.
This section designs the flexible application architecture allowing this multiple interface and the definition of various roles for any model and simulator.
%
% collaboration between the packets on a united system to facilitate the definition of divers roles  for a generic model.

\subsection{Generic construction}

\begin{figure}[!t]
\centering
\includegraphics[width=\linewidth]{imgs/Fig2-1}
\caption{Single interface structure for generic models group-ware}
\label{fig:Fig21}
\end{figure}

\begin{figure}[!t]
\centering
\includegraphics[width=\linewidth]{imgs/Fig2-2}
\caption{Evolution for multiple interface structure}
\label{fig:Fig22}
\end{figure}

To guarantee the four characteristics: genericity, extensibility, modularity and flexibility of the application, every simulation platform should be integrated as independent packages such as NetLogo or Gama in Figure \ref{fig:Fig21}. The box \emph{simulators} is the core package (or the kernel) of the simulation platform. Each simulator has a specific \emph{driver}. The \emph{simulator controller} refers to the connector package that integrates each simulator in the system. As a consequence, with such an architecture, PAMS can be extended with a theoretical unlimited number of simulators. Besides, PAMS can manage various models for one generic simulation platform. The \emph{single interface controller} package is the connector package that displays the specifications of each simulator (display outputs, possible inputs, actions that can be performed on the simulator...) in the graphical interface. This structure is detailed in \cite{PAMS:2008}. In such a structure, we can integrate easily a new simulator by implementing a specific driver for the new simulator.

Extended this architecture with a multiple interface requires to introduce a new module that can separate the common interface into personalized interfaces. We thus introduce a new module that can turn the single interface controller module into a multiple interface controller module (XML-based multiple interface controller In Figure \ref{fig:Fig22}).

%A new structure with a multiple interface suggest a new module that can change the single interface controller module called multiple interface controller module. This module will separate the common interface into personalized interface. In the Figure  \ref{fig:Fig22}, we can see a new module that is called XML-based multiple interface controller.
	
Another difficulty of separating the common interface into a multiple interface is the way to parameterize the multiple interface and to save the roles of each model. When you need a large memory space to store the results of the execution of a program, you will use an SQL database. Indeed the SQL database can manage the addition, deletion and modification of data. However, when we want to store data with a predefined structure, a stable value and that require only a small memory space, a XML file (associated to a DTD structure for the validation) is simpler and more effective. In our case, we need to describe the content rather than the presentation of content. We only need a structure to save the definition of the different roles of a model. Furthermore, when we want to change these roles, it is simple to modify the content of the XML file instead creating a new one. In addition by using the XML structure, you do not need to change the current database or other entities.

%First, we have a DTD structure to validate the generic elements of the interface.
%%
%To customize the user interface, we must determine the elements of a role that we want to display on the interface, also that the user who plays this role can monitor and view, especially the constraints among them in an independent XML file. In practice, the DTD structure allow us to clearly define this description because these structures contain a set of rules that associated with the elements of this XML document.

To customize the user interface, the modeler must determine the elements of a role that he wants to display on the interface, the control that he wants the user be allowed to use... First we need to list elements that can be displayed in each interface, then to organize them into a meta-model of the role from which we will determine the DTD of the role description XML files.


\subsection{Elements of a multiple interface}

By following the needs of participatory simulation examples presented above, we identified in Table \ref{table_elements} the elements that we have to customize to construct a multiple interface.

\begin{table*}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
\caption{Elements of a role in participatory simulations}
\label{table_elements}
\centering
\begin{tabular}{|l|l|}
  \hline
  % after \\: \hline or \cline{col1-col2} \cline{col3-col4} ...
  Type of elements & Description \\
  \hline
  User & Participants of simulation \\
  \hline
  Role & According to this role, the user who deployed the model will determine what role can follow. \\
  \hline
  Agent & Agent who can be controlled by participant in his interface \\
  \hline
  Parameter & The parameters that a participant can view and modify \\
  \hline
  Output & The outputs that a participant can observe their results \\
  \hline
  Action & The action that a participant can take \\
  \hline
\end{tabular}
\end{table*}


%% Added from section II - by Nhan
%%
%%
%
%On the agent-based participatory simulation, the separation of roles between experts is very important. The stakeholders will take part and have the influences in their participation on the execution of simulation. They should access to control the simulation on a remote server, to observe and initialize the correspondent parameters of simulation, and to view the results according to their domain.
%
%The collaborative framework has a multiple interface for making use of the expertises and experiences of domain experts. Each personal interface agrees to a role that supports certain rights. A clear separation will avoid the concurrent among various specialities and help the researchers to work on the familiar data that keep only the variables and actions correspond to see and control an agent. The social construction of the experimental process should ensure the decision processes at the levels of the expertise, and the simulation work groups. The role of each research should be explicit.
%
%It is necessary to find the related elements in a collaborative simulation process to personalize in the multiple interface. Such a experimental process have two core components: (i) the choice of the participants in a experimentation (the social construction in real world) and (ii) the choice of simulation scenarios (the simulator model) \cite{Daniellou:2007}. The second component will be set by two elements: inputs and outputs as the core of this component. The modeller will choose a model and invite the participants to this project. The choice of model depend on the field of their exploration that decide the inputs and outputs. The choice of the participants is based on their knowledge that are required to perform the simulation. And each participant will receive a suitable role. These participants can initialize the parameters, execute this simulator and observe the outputs on the view of their personal interface that designed for a role. The experience and knowledge about a special domain research will help the participant to control the inputs of simulator effectively. The researchers change the inputs of the simulation or change the actions of agents to get the desired outputs. In this situation, groups of participants are invited to take part in simulations about the future work system \cite{Daniellou:2007}.
%
%%
%%
%% End add from section II
The elements for the concept of collaborative and participatory simulation are: parameter, input, output, action, role, and user. For a specific role, the modeler has to define the agents that the user playing his role can control and/or observe, which variables (parameters) he can modify and  which outputs (monitors, graphs, displays ...) he can watch. For example, an user who plays the role of a coordinator of the firemen can control all the agents ``fireman'' on the screen. He can change the initial parameters of agents ``fireman'' such as: the speed, the water, the range of water... But he can only view the monitor that displays the percent of remained water. However, he cannot view or control the elements of the others agents.

%
%
%With a specialized role, each user plays a role of agent, variables (or parameters) and outputs (monitors, graphs, displays ...). These information are defined by modeler in the conception phase. To define a new set of roles for an available model, the modeler will continue to describe on an XML configuration file for the participatory simulation, for example, a user who plays the role of a firefighter can control all the agents ``fireman'' on the screen. He can change the initial parameters of the agent ``fireman'' such as: the speed, the water, the range of water... He can only view the monitor that display the percent of remained water. However, he cannot view or control the elements of the others agents.
%
%All generic terms: elements, attributes, entities and their constraints will be preset by DTD structure. The work for the configuration is to write an XML file to declare ``firefighter'', ``speed'', ``range'', etc. by using concepts and constraints that are predefined.


\subsection{Generic meta-model}

\begin{figure}[!t]
\centering
\includegraphics[width=\linewidth]{imgs/Fig3}
\caption{Meta-model for role design}
\label{fig:Fig3}
\end{figure}

With above elements needed for a multiple interface, we design a meta-model of the notion of role (Figure \ref{fig:Fig3}).
The main element is the ``Role'' affected to each user. The main idea of this meta-model is that a role is defined in terms of what he can view and what he can control. The ``ViewAccess'' defines mainly the elements the user can observe. We define only one kind of view: the ``VariableView''. In our model, the variables include the parameters and the outputs of the model. The ``ControlAccess'' gathers the controllable elements. Three types of control have been defined: the control to add a new output (that the user will observe), the control to change the value of a simulator parameter in a experimental process.
%
The last control is the ``SimulationControl''. It means that the user can run the simulation or not.

We consider that the role of the user who creates a new experiment is by default ``DOES''. This role allows the creator to see all the outputs and change all the parameters.

%With concepts of above elements of a multiple interface, we design meta-model that allows to describe the elements on the DTD structure. The new concept will help us to determine this role that defines the information he can view and the elements he can control. For each interface, the system will show correspondent information and elements. In addition, information of a participant are more precise, more concrete. They are displayed on the screen of each participant.
%
%In this collaboration meta-model, we determined the elements that we customize a multiple interface. The main idea is following: the main element is the ``Role'' that each user is distributed only one time. Each ``Role'' has the rights to view or control. The ``ViewAccess'' defines the elements to view the variables. In our concept, the variables content the parameters and the outputs of a model. The ``ControlAccess'' sets the controllable elements. Two types of control we defined are to add a new output for observing and to change the value of a simulator parameter in a experimental process.





\subsection{XML-based solution}

According to above meta-model, we can give the structure of the DTD document (Figure \ref{fig:Fig4}) that describes the grammar of the XML files that will define the various roles and will be used as configuration files for the multiple interface.

\begin{figure}[!t]
\centering
\includegraphics[width=\linewidth]{imgs/Fig4-code}
\caption{DTD structure for validating XML roles file}
\label{fig:Fig4}
\end{figure}

We consider that one XML describes at most one simulator. The root element contents different roles for the model that is specified by the attribute ``model''. Each element ``role'' has a private name defined by the attribute ``name''. A role has different rights that correspond to the tags ``accesscontrolview''. Furthermore, the right for a role to control the simulation (launch, stop, start, pause) depends on value of the boolean attribute ``isControlSimulation''. The value of a tag ``accesscontrolview'' correspond to a name of an input or an output of the simulator. It indicates that this role has the right to view this element. The tag ``accesscontrolview'' has an attribute ``type'' to determine whether this element is an input or an output. Finally, the boolean attribute ``isControl'' will specify whether this element can be controlled by this role. We summarize this description in the Table \ref{table_example}.

\begin{table*}[!t]
\renewcommand{\arraystretch}{1.3}
\caption{Elements of any role in DTD structure}
\label{table_example}
\centering
\begin{tabular}{|l|l|l|}
  \hline
  % after \\: \hline or \cline{col1-col2} \cline{col3-col4} ...
  Tag & Nom & Description \\
  \hline
  \hline
  ELEMENT & Simpart & Element ``root'' that contents various roles \\
  \hline
  ATTLIST & Model & Attribute indicate ID of the model \\
  \hline
  ELEMENT & Role & Element ``role'' represents a role that contents various rights. Each right is a tag ``accesscontrolview'' \\
  \hline
  ATTLIST & Name & Attribute that indicates the role name \\
  \hline
  ATTLIST & isControlSimulation & Attribute that specifies the right to launch the simulation. Default: he can. \\
  \hline
  ELEMENT & accesscontrolview & Element represents every right of role. Its value is the name of the parameter or  \\
       &                      & of the output that is saved in the mySql database. \\
  \hline
  ATTLIST & type & Attribute that indicates the type of parameter or of the output. Default: parameter \\
  \hline
  ATTLIST & isControl & Attribute indicates the right to modify a parameter. Default: He cannot. \\
  \hline
\end{tabular}
\end{table*}
